Link contains Base64 encoded presigned URL and then there is encryption key. At best we could reduce size by ~20% by removing the encoding, but link instead of "random" Base64 output would still be too long and would then contain more "hackish" words, so I am not sure if that's any improvement.
An example link would look similar to this instead:
https://s3.amazonaws.com/finance-department-bucket/2022/tax-certificate.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA3SGQVQG7FGA6KKA6%2F20221104%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20221104T140227Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=b228dbec8c1008c80c162e1210e4503dceead1e4d4751b4d9787314fd6da4d55
I don't think this is a solution either.
In one of the next releases we will support shorter links e.g.: /share/b4d049e8-ae9e-47ee-a60d-abd45a7af4bd
or /share/b4d049e8-ae9e-47ee-a60d-abd45a7af4bd#UkM0nw/i8tpzjxeV6ry3xQ==
for encrypted shares, but only for storage that we provide.
This is because we will provide this convenience layer from our API directly, that's not something we can achieve using S3 natively.
Your best bet might be using some link shortener, however bear in mind that you probably you wouldn't want to paste your whole share link including the: #
as you give away the encryption key to link shortener service.
You would probably want for the redirect to apply only to link part before #
, which implies that after you create short link the encryption key after: #
shall be appended manually.
We might provide some built-in link shortener service in the future. This could potentially allow providing non-expiring links, as we would regenerate the underlying link whereas the shortened one wouldn't change. (edited)